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Remarks ; 

This amendment is submitted in an earnest effort to 
advance this case to issue without delay. 

The specification has been amended to eliminate some 
minor obvious errors and place it in somewhat better US form. No 
new matter whatsoever has been added. 

The claims have been amended to define the invention with 
greater particularity over the art. 

In the following, in order to avoid any doubt that new 
matter has been added, references to page and line numbers refer to 
the published PCT case, the WO version. 

In claim 1, the expression "routing data"is replaced by 
the expression "content related data", defined in the claim as the 
"data related to the association of contents and the caches that 
contain them" so as to distinguish them from the "routing data" 
that is the data transferred from the interface component to the 
Directory Name Service or Domain Name Server of the respective 
network. In addition, the amended claims clarify that the routing 
data are "obtained by processing the content related data" and are 
transferred from the interface component to the Domain Name Server 
"so as to update tables of the Directory Name Service or Domain 
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Name Server". Support for these amendments is found throughout the 
whole specification (see e.g. page 7, lines 1-3 and FIGS. 10-13 
plus the relevant description, e.g. page 11, lines 19-21 and claim 
18 as filed) . 

The claims also clarify that the "Directory Name Service 
or Domain Name Server is "different from the at least one interface 
component" as is clear from the whole specification, e.g. FIGS • 1, 
2 and 13 and relevant description. The feature of having the 
interface component different from the Domain Name Server is also 
implicit in claims 1, 4 and 7 as originally filed, the interface 
module DNSI being used for interfacing with the Domain Name Server 
and for "transferring" data from the interface component to the 
Domain Name Server. 

Independent claims 4 and 7 have been amended accordingly. 

Some formal changes have been introduced into the 
dependent claims to correct errors and the dependency of claims 13, 
14, 18 has been corrected. 

Independent claims 1, 4 and 7 stand rejected under §102 
on US patent 6,289,382 of Bowman-Amuah. This reference has an 
extremely long specification and almost 200 drawing figures and, 
practically speaking, includes a broad review of the state of the 
art on computer science (in itself and as applied to 
telecommunications) as of the filing date in August 1999. For this 
reason, the Examiner has been able to find in this document a 



- 14 - 



Atty's 23083 Pat. App. 10/512,018 

reference to most of the features that, combined together, make our 
independent claims* 

Nonetheless, the technical content of Bowman- Amuah is 
remote from our invention, which specifically relates to 
internetworking of Content Delivery Networks, a technical subject 
not even dealt with in Bowman- Airmail . The various features of our 
claims are mentioned separately in Bowman-Amuah, each one within a 
completely different context from the others. It is really 
difficult to imagine the motivation the skilled in the art would 
need in order to make a specific selection and combination of 
features like the ones claimed here. 

For example, the passage at column 242, lines 16-ff of 
Bowman-Amuah, relied upon by the Examiner in rejecting, claims 1 
and 4, refers to bundling "all the necessary data into a single 
data structure that can be transmitted as a structure across the 
network". In this scheme, all data needed by a Client are bundled 
together into a data structure and returned to the client. Then 
"the client will cache this data ... on its local machine and use 
it as needed" • The meaning of "caching" in this passage of Bowman- 
Amuah is quite different from that used in our claims. In our 
claims, caches are included in the set of Content Delivery Networks 
that are internetworked in the invention. From these caches, 
content is distributed to clients. Our invention has to do with 
passing to clients the information on how to reach a cache in a 
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Content Delivery Network, to get content from that cache. Hence 
the above- referenced passage of Bowman -Amuah does not disclose 
anything that would be used by the skilled person in combination 
with Content Delivery Networks (with caches that are not on the 
client local machine and are, to the contrary, part of the Content 
Delivery Network) . 

According to the instant invention as defined in the 
amended independent claims, access by the client of a respective 
network to contents of the networks in a set of CDNs is implemented 
through the Directory Name Service or Domain Name Server of this 
network, the Domain Name Server being different from the interface 
component associated with a respective network and the interface 
component itself updating the Domain Name Server tables. 

This makes it possible to implement a request -routing 
functionality based solely on the Domain Name Server, which in turn 
has its tables maintained updated by the interface component, without 
the interface component having to perform Domain Name Server 
functions, e.g. address resolution. 

In particular, the instant invention as described from page 
2, line 31 to page 3 line 9 of the (PCT) specification allows one to 
avoid duplication of functions (e.g. address resolution) between the 
Domain Name Server and the interface component associated with a 
respective network. 
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Thus the instant invention as defined in the claims is 



clearly allowable over the cited art. Notice to that effect is 
earnestly solicited. 



If only minor problems that could be corrected by means 



of a telephone conference stand in the way of allowance of this 
case, the examiner is invited to call the undersigned to make the 
necessary corrections. 



14 December 2007 

5683 Riverdale Avenue Box 900 

Bronx, NY 10471-0900 

Cust. No.: 535 

Tel: 718 884-6600 

Fax: 718 601-1099 

Email: email&kfxroc . com 

Enclosure: Request for extension (three months) 



Respectfully submitted, 
K.F. Ross P.C. 




^Ajidrew Wilford, 26,597 
Attorney for Applicant 
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METHOD FOR IMPLEMENTING CONTENT DELIVERY NETWORK (CDN) INT 

CROSS REFERENCE TO RELATED APPLICATIONS T ec hni c al Field 
This application is the US national phase of PCT 
application PCT/EP2003/04059, filed 17 April 2003, published 30 
5 October 2007 as WO 2003/090423, and claiming the priority of 

Italian patent application TO2002A000341 itself filed 19 April 
2002, whose entire disclosures are herewith incorporated bv 
reference. 

FIELD OF THE INVENTION 
10 This invention relates in general to techniques 

generally known as "internetworking" . 

BACKGROUND OF THE INVENTION 
In general terms , the basic objective of 
internetworking is the co-operation and interoperability of 
is elementary systems (seen as "black boxes") to create a 

macrosystem capable of presenting the characteristics of the 
constituent systems with the addition of a number of advantages. 
Ba c k g r o und Art 

First [[ly]]/ when two or more different administrative 
20 entities reach an internetworking agreement they extend (within 
contractual limits) their respective catchment areas without 
additional expenses for wiring or structural purposes. It is 
reasonable to think that the service quality perceived by the 
final user may be increased due to the larger size of the 
25 reference network. 

In the specific case of the so-called Content Delivery 
Networks, or CDNs, additional contents and diversification is 
also provided. 
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For its very nature, an internetworking solution 
requires the presence of interface components which, on 
elementary system (i.e. single CDN) side have a complete overview 
of the evolution of the static and dynamic characteristics and 
5 which on the "rest of the world" side (i.e. on the side of the 
other internetworking networks, that is on peer side) have only 
the comprehensive information needed to establish profitable 
intersystem communication. The term "profitable" here means 
efficient, safe and reliable being provided with the mechanisms 

10 that this type of solution entails. 

Regulations concerning the matter are currently being 
drawn up, as documented, for example, by the following draft 
standards published by IETF (Internet Engineering Task Force) 
which can be retrieved from the organization's web site, namely: 

15 "A Model for CDN Peering", by M. Day, B. Cain, G. Tomlinson and 
P. Rzewski, May 2001; "Content Internetworking Architectural 
Overview", by M. Green, B. Cain, G. Tomlinson, S. Thomas e P. 
Rzewski, March 2001; "Known Mechanisms for Content 
Internetworking", by F. Douglis, I. Chaudhri and P. Rzewski, 

20 November 2001. 

The interface components are called Content 
Internetworking Gateways or CIGs. CIGs have a complete overview 
of the environment within their respective CDN and perceive the 
data related to remote environments through protocols for 

25 exchanging data, called "advertisement". 

From an abstract point of view, a CIG must route 
requests (i.e. perform request -routing functions), on the basis 
of all data from the pre-existing infra-CDN modules (distribution 
system and monitoring system) and equivalent remote devices. 
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According to the aforesaid standards, the CIG routes a 
client's content requests. 

Specifically, having received a request for a certain 
content and having verified that the content is available in its 
5 respective CDN, the CIG sends the corresponding required content 
cache ID to the client. The concerned CIG is consequently 
capable of routing the request, also when the content is hosted 
in the cache of another CDN. 

In this situation, when several CDN networks are 
10 internetworking, the CIGs perform address resolution and content 
request -routing functions, which on internet level are remitted 
to other network members, particularly by involving the so-called 
DNS (Directory Name Service or Domain Name Server) . 

This leads to splitting/duplication of functions which 
is causes several problems. The problems are related, among other, 
to the need of ensuring correct synchronisation between CIGs and 
devices in the Internet and to the fact that the request from a 
certain client is processed differently according to whether the 
request involves the CDN level or not. 
20 OBJECT Discl o sure OF THE INVENTION 

The object of the invention is to overcome these 
shortcomings . 

SUMMARY OF THE INVENTION 
The object is obtained according to the invention 
25 thanks to a procedure w h o se c ha r act e risti c s ar e r e c it e d in the 
annex e d c laims basically comprising the steps of collecting in 
the interface components CIG routing data related to the 
association of the contents and the caches which contain them; 
and transferring the routing data from at least one of the 
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interface components to the Directory Name Service or Domain Name 
Server of the respective network, so that access by the client of 
the respective network of contents of the networks in the set of 
CDN is implemented through the Directory Name Service or Domain 
5 Name Server (DNS) of the network . The invention also relates to 
a corresponding system of internetworking CDN networks and a 
respective interface or CIG component. 

BRIEF DESCRIPTION OF DRAWINGS 
The invention will now be described, by way of example 
io only, with reference to the accompanying drawings wherein: — 
Fi g ure 

FIG. 1 generally illustrates the internetworking 
organization criteria of two CDN networks, — Fi g u re 

FIG. 2 generally illustrates the structures of a 
is Content Internetworking Gateway, or CIG, according to the 
invention, - Fi g u re s 

FIGS. 3 and 4 illustrate different infra-CDN and 
inter-CDN request -routing methods, * — Fi g u r es 

FIGS. 5 to 7 illustrate the typical CIG context 
20 diagrams at various levels detail according to the invention, 
Fi g ur e 

FIG. 8 shows the finite state automaton of a 
corresponding CIG, < — Fi g ur e 

FIG. 9 is a time diagram showing the opening of a 
25 corresponding session, and — Fi g ur e s 

FIGS. 10 to 13 illustrate the format of the various 
messages exchanged by a CIG according to the invention. 

BEST MODE FOR CARRYING OUT THE INVENTION 
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The diagram in fi g ur e FIG. 1 illustrates the 
collocation of two Content Internetworking Gateways (hereinafter 
called CIG for short) intended to permit exchange of 
" advert izement" data in the context of a set formed by two 
s Content Delivery Networks CDNl and CDN2 in combination with an 
Origin Server (OS) each. 

Each CDN shown here consists of a respective 
administrative domain with a Directory Name Service or Domain 
Name Server (DNS for short ), management center, cache memories 
10 and connections to client function terminals. 

fi g ur e FIG. 1 shows the role of the ClGs in the 
internetworking process. One of the specific characteristics of 
a CIG is the degree (or level) of integration as a parameter, 
respect to the modules which are already present and operational 
15 within a CDN. 

The higher or lower efficiency of the respective 
interface functions can be assessed according to this parameter. 

fi g ur e FIG. 2 briefly illustrates the interface 
components which form a CIG according to the invention in the 
20 currently preferred form of embodiment. 

Specifically, the concerned CIG consists of: [[-]] 

a first interface module, called Request -Routing 
Interface or RRI, which exchanges data with the remote CIGs 
according to CNAP protocol specifications (described in detail in 
25 the description that follows), [[-]] 

a second interface module, called DNS Interface or 
DNSI, which interfaces with the DNS of the CDN to which the CIG 
belongs, [[-]! 
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a third interface module, called Distribution 
Information Interface, or DII, which retrieves data on the 
availability of contents from the distribution system of the CDN 
to which the CIG belongs, [[-]] 
5 a forth interface module, called Monitoring Information 

Interface, or Mil, which interacts with the monitoring system, 
and finally [[-]] 

a central module, called Request -Routing Process, or 
RRP, which collects and processes the information received to 
io implement the request -routing function: the latter module is the 
CIG core. 

It is noted that the aforesaid architecture, although 
preferred, is not absolutely imperative or binding, at least as 
concerns the presence of the third or fourth interface module 
15 described above. 

Further reference to the CNAP protocol may be found in 
<BR> <BR> "Content Network Advertizement Protocol (CNAP) "by B. 
Cain, O. Spatscheck, L. Amini, A. Barbir, M. May and D. Kaplan, 
November 2001, which may also be retrieved from the IETF web 
20 site. 

Briefly, the CIG consists of a central module which is 
the "brain" of the device and a certain number of interface 
modules between the CIG and the pre-existing infrastructure. 

The described request -routing technique solution refers 
25 to modules implementing DNS technology. 

Consequently, two likely internetworking scenarios may 
be hypothesized and illustrated in an event trace diagram. 

fi g ur e FIG. 3 shows a classical content routing 
scenario, so to speak, the term herein indicating a standard 
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routing process in a CDN (implementing DNS technology) in which 
DNS table updating is delegated to the CI6 by means of the DNSI 
module. 

Extending the example to an actual internetworking case 
5 is easy with this procedure. 

The labels and the directions of the arrows in the 
figures help to understand the real sequence of events: a user 
makes a content request to the DNS system which works in standard 
mode. The DNS responds with the best surrogate IP address 

io according to the routing policies applied at the time* The CI6 

periodically updates the DNS tables , according to the information 
received from the distribution and monitoring system; note that 
in this first case, the system is "isolated", so to speak. 

Conversely, in the situation in fi g ur e FIG. 4, the 

is selected surrogate servers belong to another administrative 

domain, i.e. CDN. The dynamics appears essentially similar to 
the example above. In this case, as above, the client queries 
the DNS which replies with the best surrogate server IP address. 
The difference is in the data retrieving and updating method. 

20 The bi-directional arrows in the central section indicate the 

periodical exchange of routing data between entities on the same 
hierarchic level (peers), i.e. the CIGs, according to the 
conventions and the specifications of the CNAP protocol. This 
type of data is similar to infra-CDN data, and used by a CIG to 

25 update the DNS tables on the basis of a wider range of data with 
respect to that which occurs in known architectures. 

The roles of the modules which form a CIG operating 
according to the invention will now be described with reference 
to the diagram indicated by the acronym DFD (Data Flow Diagram) • 
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The higher level approach consists in the use of a so- 
called context diagram. The diagram represents the interactions 
between the whole CI6 and the "outside world". 

As shown, the CI6 appears as a single entity capable of 
5 interacting with the rest of the world. 

The CI6 routes requests according to the information 
from the other entities with which it communicates. More in 
detail, it receives data from peers, from the distribution system 
and the local monitoring system. After processing, the data, the 
10 DNS tables and the log file archives are updated. 

At this point, the request-routing system can be 
observed closer, by splitting into subsystems and representing 
the functions on different levels of detail. 

Two subsequent expansions are illustrated in fi g ure 
is FIG. 6 and fi g ure FIG. 7 7 — r e s p e c tively . 

Specifically, the interface processes clearly appear in 
fi g u re FIG. 6, corresponding to a first level of detail: these 
are "buffer" modules which communicate with the central process 
on one side and with the outside world on the other. 
20 fi g ure FIG. 7, on the other hand, illustrates the 

functions of the RRP core. The RRP receives data from the rest 
of the world and transmits them via the interfaces, extracts 
useful information on cache and/or content state, evaluates the 
need to update and consequently modifies its own database, the 
25 DNS tables and the log file archives. 

Finally, if required, it sends the message to its 
peers, through the request -routing interface RRI. 

The request-routing interface RRI interfaces with the 
rest of the world. From this point of view, it is the most 
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important module in the internetworking procedure, because it is 
directly implied in inter-CDN communication; as mentioned above, 
this communication is carried out according to the conventions of 
the CNAP protocol which was designed for this purpose. 
5 This module is responsible for translating the messages 

from CNAP (inter-CDN) format to a format which can be understood 
by the CIG (infra-CDN) central process, or RRP • The CNAP 
protocol requires initial specifications (and periodical 
updating) or a set of data, which are static so to speak, 
io referred to the internetworking system topology characteristics. 
For example, the following may be requested: [[-]] 

the local CNAS ID (i.e. the CDN to which the concerned 

CIG belongs) ; [ [-] ] 
the IP address of the local CIG computer; [[-]] 
is the CNAS INFORMATION DISCLOSURE STATEMENT of remote 

interconnected systems (peers) with which 
internetworking will be established; [[-]] 
the IP addresses of the remote CIG computers 

corresponding to the systems mentioned in the 
20 point above; [[-]] 

the inter-CNAS level of confidences; and - a numeric 
coefficient indicating the "weight" in static 
conditions of each connection (practically similar 
to the geographical distance of the connection) . 
25 The protocol offers the possibility of diversifying the 

contractual internetworking relations with the introduction of 
level of confidences. In other words, before disseminating 
information on availability of a content to a remote CIG, the 
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local CI6 verifies whether the CI6 is enabled to received the 
information according to the stipulated contact. 

The CNAP connections, as required by the IETF for 
internetworking protocols, implement a reliable connect ion - 
5 oriented protocol on transportation level: for example, TCP 

(Transmission Control Protocol}, currently employed in Internet 
contexts, may be used. 

The logical operations needed to establish a CNAP 
session are shown below. 
io This is carried out with specific reference to the 

finite state automaton diagram of the CI6 as illustrated in 
fi g ure FIG. 8. 

During the initial state of the CIG, called IDLE, there 
is no CNAP session and no entity has intervened to change this 
is situation. When the CIG intends to establish a CNAP session with 
a remote CIG, it sends an OPEN message and goes to OPENSENT 
state • 

The remote, also initially in IDLE state, receives a 
request to open a CNAP session. It replies with a KEEPALIVE 
20 message and goes to OPENCONFIRM state. 

Two cases may occur [ [ . ] ] ± 

In the first case, the original CIG receives the 
KEEPALIVE message within a predetermined lapse of time: in this 
case, it goes to READY state and waits to send advertizement 
25 messages (i.e. messages carrying useful data, not only metadata, 
as initialization messages) . 

In the second case, the predetermined time-out expires 
before the original CIG receives the expected KEEPALIVE message: 
in this case, it returns to IDLE state and the communication 
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attempt fails. In general , a NOTIFY message will inform the 
parties of the anomaly. 

The remote CIG, having sent the following KEEPALIVE 
message, also goes to READY state and listens out for 
5 advertisement messages to be received. 

The reception of a NOTIFY message makes the CIG go to 
IDLE state. As may easily be assumed from the description above, 
the CNAP connection is active and efficient if both involved CIG 
are in READY state. 
io fi g ure FIG. 9 shows the sequences of state which 

characterize opening of a CNAP session and highlight the 
evolution of events in time. 

The messages exchanged by the RRP core and the 
request -routing interface RRI may have the format shown in fi g ur e 
is FIG. 10. 

The meaning of the message fields is shown below: 
URL: is the URL identifying the content of the message; 
IP: is the IP address of the cache which distributes 
the contents; 

20 CNAS ID: is the ID of the CDN to which the cache 

belongs ; 

CACHE STATE: is the state of the cache; 

CONTENT STATE: is the state of the content in the 

cache; TTL: is the life time of the routing data. 
25 The monitoring interface Mil is the module which 

implements the interface between the RRP core and the local 
monitoring system, i.e. referred to the CDN to which the CIG 
belongs. The data which must be transferred to the RRP refer to 
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the CDN cache state; the term "state" here indicates 
quantification of the available resources. 

In this perspective, the format of a message from the 
monitoring interface Mil may assume the appearance shown in 
5 fi g ure FIG. 11. 

The message has five fields whose meaning is 
illustrated below: 

IP: the IP address of the cache to which the message 
refers; 

10 CPU: percentage of CPU used by the cache; 

MEM: percentage of RAM used by the cache; 
DISC: percentage of disc used by the cache; 
USERS: percentage of the number of connected users (in 
relation to the maximum service capacity of the 
is concerned cache) . 

The parameters are classical performance indicators 
which are used to assess the conditions of use of the cache. 
Messages of this type are passed to the RRP at regular intervals 
of time. 

20 The DII distribution interface is the interface module 

between the distribution system and the RRP core of the CIG. The 
DII interface collects information on the presence and 
availability of the cache contents, fi g u re FIG. 12 shows the 
format of a possible message of this type. 
25 The meaning of the fields is shown below: 

URL: is the URL identifying the content to which the 

message refers; 
CACHE: is the list of IP addresses of the caches in 
which the content is available; 
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LEVEL OP CONFIDENCE: is the level of confidence of the 
content; 

CONTENT AVAILABILITY: indicates whether the content is 
available or not; 
5 CACHE STATE: is the status of the cache; 

TTL: indicates the life time of the routing data. 
Three levels of confidence can be associated to the 
contents, i.e.: 

low-contents can be exchanged with all interconnected 
10 CDNs; 

medium- contents can be exchanged only with CDNs which 
have subscribed a MEDIUM level confidence 
agreement with the CDN that owns the content; and 
high- contents can be exchanged only with CDNs which 
15 have subscribed a HIGH level confidence agreement 

with the CDN that owns the content. 
The DNS interface, indicated by DNSI, is the interface 
module which must communicate with the DNS server, to update the 
tables. A possible format of the message useful for this purpose 
20 is shown in fi g ure FIG. 13. 

The meaning of the respective fields is: 

OP: indicates the operation to be carried out on the 

DNS table (two operations are available, "add" and 
"delete" ) ; 

25 REG TYPE: indicates the type of register; 

DOMAIN NAME: indicates the name of the domain to which 

the message refers; 
IP: is the address of the best cache IP address to 

serve the domain above; 
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TTL : is the life time of the register. 
Alternatively, the DOMAIN NAME field may contain the 
entire URL of the content to which the message refers. In this 
way, the DNS can directly identify the best cache for content 
5 delivery. 

The request -routing module RRP is, as mentioned above, 
the core of the system. It is responsible for processing the 
data received from the aforesaid interface modules, updating the 
DNS tables if required via the DNSI interface and forwarding the 
io data to the other CIGs through the RRI interface. 

It is also responsible for managing the log file 

archive . 

Given the need to enable the respective DNS to perform 
the address resolution function (to make content delivery 

is factually "transparent" with respect to the presence of a set of 
internetworking CDN networks), the RRP core must have a data 
structure which will store the states of the local CDN and the 
remote CDNs. The data structure must collect and organize the 
data referred to contents available in the internetworking system 

20 context and to the caches capable of providing the contents. 
Data structure definition is periodically updated by the RRP 
module, in a different way according to the type of message which 
prompted the updating process on a case-by-case basis. 

Naturally, numerous changes can be implemented to the 

25 construction and embodiments of the invention herein envisaged 
without departing from the scope of the present invention, as 
defined by the following claims. 
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